---
sidebar_position: 1
id: lectures-gitcicd-ci-cd-intro
slug: lectures/gitcicd/ci-cd
---

# Что такое методология CI/CD?

Простыми словами, CI/CD (*Continuous Integration*, *Continuous Delivery* — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчики, аналитики, инженеры качества, конечные пользователи и др.).

## Основные принципы CI/CD

- **Сегрегация ответственности заинтересованных сторон**. Участники процесса разработки и потребители готового проекта разделяют между собой ответственность за ту или иную стадию жизненного цикла продукта. Разработчики и дизайнеры проектируют бизнес-логику, а также обеспечивают положительный пользовательский опыт взаимодействия с готовой системой. Инженеры по качеству вводят сквозные функции и приемочные тесты, DevOps-инженеры организуют логистику кода, а пользователи — дают обратную связь по результатам использования системы.
- **Снижение риска**. Каждая группа участников процесса разработки минимизирует возможные риски при прохождении продукта через стадии жизненного цикла (контроль целостности бизнес-логики, пользовательского опыта, оптимизация хранения и обработки данных, миграции и пр.).
- **Короткий цикл обратной связи**. В коммерческой разработке скорость реакции на возникновение ошибок, либо запросов нового функционала закладывает основу конкурентоспособности будущей системы. Чтобы добавлять в продукт новый функционал быстрее конкурентов, необходимо стремиться к автоматизации сборки и тестирования кода. Однако, в ситуациях, когда для решения необходимо участие человека, автоматизация может только навредить. Для таких ситуаций рекомендуется сокращать число информационных посредников, обеспечивая короткий цикл обратной связи.
- **Реализация среды**. Команде разработки требуется единое рабочее окружение для контроля версий и построения вспомогательных веток для целей контроля качества, приемлемости, масштабируемости и отказоустойчивости производимого кода. По мере контроля протестированные модули должны перемещаться в основную ветку проекта и поступать на тестирование и сборку в составе единого решения. На этапе финального тестирования код также оценивается с позиций безопасности.

## Этапы CI/CD

*Типичную итерацию процесса разработки с применением CI/CD (источник [doka.guide/tools/ci-cd](https://doka.guide/tools/ci-cd/))*:

![CI/CD flow](images/ci-cd-flow.png)

Детализированное описание этапов:

- **Написание кода**. Каждый из разработчиков пишет код своего модуля, проводит ручное тестирование, а затем соединяет результат работы с текущей версией проекта в основной ветке. Для контроля версий используется система Git, либо аналогичные решения. Когда участники команды опубликуют код своих модулей в основной ветке, начнется следующий этап.
- **Сборка**. Система контроля версий запускает автоматическую сборку и тестирование проекта. Триггеры для начала сборки настраиваются командой индивидуально — фиксация изменений в основной ветке проекта, сборка по расписанию, по запросу и т.д. Для автоматизации сборки используется Jenkins, либо аналогичный продукт.
- **Ручное тестирование**. Когда CI система успешно проверила работоспособность тестовой версии, то код отправляется тестировщикам для ручного обследования. При этом тестовая сборка получает номер кандидата для дальнейшего релиза продукта (например, v.1.0.0-1).
- **Релиз**. По итогам ручного тестирования сборка получает исправления, а итоговый номер версии кандидата повышается (например, после первого исправления версия v.1.0.0-1 становится v.1.0.0-2). После этого выпускается версия кода для клиента (например, v.1.0.0) и начинается следующий этап цикла.
- **Развертывание**. На этом этапе рабочая версия продукта для клиентов автоматически публикуется на production серверах разработчика. После этого клиент может взаимодействовать с программой и ознакомиться с ее функционалом как непосредственно через готовый интерфейс, так и через облачные сервисы.
- **Поддержка и мониторинг**. Конечные пользователи начинают работать с продуктом. Команда разработки поддерживает его и анализирует пользовательский опыт.
- **Планирование**. На основе пользовательского опыта формируются запросы на новый функционал для продукта, готовится план доработок. После этого цикл замыкается и переходит в начальную стадию — написание кода. Далее начинается новая итерация CI/CD разработки.

*Да благословят боги сей расчудесный мир!*:

![CI/CD meme](images/ci-cd-meme.png)

## Инструменты для CI/CD

Разработчики программного обеспечения используют различные инструменты для автоматизации тестирования и доставки кода своих проектов конечным пользователям.

- **GitLab**. Среда позволяет управлять репозиториями проекта, документировать функциональность и результаты доработок и тестов, а также отслеживать ошибки и работать с CI/CD pipeline.
- **GitHub**. Среда позволяет управлять репозиториями проекта, документировать функциональность и результаты доработок и тестов, а также отслеживать ошибки и работать с CI/CD с помощью GitHub Actions.
- **Travis-CI**. Инструмент подключается к репозиториям в GitHub при минимуме настроек. Решение облачное и не требует локальной установки. Кроме того, оно бесплатно для open-source проектов.
- **Circle-CI**. Продукт также использует бесшовную интеграцию с GitHub. Предлагается веб-интерфейс для отслеживания версий сборок и ведения задач. Также решение поддерживает отправку оповещений по почте, slack и другим каналам связи.
- **Jenkins**. Довольно популярный инструмент в DevOps среде. Заслужил свою репутацию благодаря работе с различными плагинами, позволяющими гибко настраивать CI/CD процессы под требования разработки конкретного продукта.
- **TeamCity**. В бесплатном режиме позволяет работать только с 3 агентами сборки, техническая поддержка предоставляется по подписке.
- **PHP Censor**. CI-сервер для автоматизации сборки PHP-проектов, работающий с репозиториями GitLab, GitHub, Mercurial и др. Для тестирования используются библиотеки Atoum, PHP Spec, Behat и др. Проект хорошо документирован, но предполагает самостоятельную настройку и хостинг.
- **Rex**. Предназначен для автоматизации CI процессов в дата-центрах. Функционирует на Perl-скриптах.
- **Open Build Service** (OBS). Предназначен для автоматизации CI/CD в разработке дистрибутивов приложений.
- **Buildbot**. CI-система, позволяющая автоматизировать сборку и тестирование приложений. Поддерживает современные VCS и позволяет гибко настраивать сборку за счет Python-компонентов.

И это лишь малая часть инструментов для CI/CD.

*Инструменты для CI/CD (источник [harness.io/blog](https://harness.io/blog/continuous-delivery-tools))*:

![CI/CD Tools](images/ci-cd-tools.png)

## Преимущества и недостатки

Преимущества:

- Инструменты CI/CD позволяют быстро выводить программный продукт на рынок, исправлять ошибки, внедрять новую функциональность.
- Автоматизация позволяет снизить нагрузку на членов команды, облегчает тестирование и уменьшает количество ошибок в каждой итерации. Главный плюс — это быстрая обратная связь.
- Гибкий план позволяет быстро перераспределять ресурсы команды на решение действительно важных задач.

Недостатки:

- Часто инструменты CI/CD воспринимаются как швейцарский нож, который может справиться с любыми задачами. При недостатке опыта это может приводить к существенному усложнению процессов в команде.
- Инструменты CI/CD не могут решить проблемы взаимодействия внутри команды, обо всём придётся договариваться.
- Все члены команды должны работать в единой экосистеме.

Подробнее о CI/CD:

- [doka.guide/tools/ci-cd](https://doka.guide/tools/ci-cd/).

## Атрибуция

При подготовке статьи использован материал:

- [selectel.ru/blog](https://selectel.ru/blog/what-is-ci-cd/)
- [doka.guide/tools/ci-cd](https://doka.guide/tools/ci-cd/).
